Enterprise Service Bus

Complex it infrastructures require modern architecture principles in order to cope with the challenging requirements that a evolving it-infrastructure has. For this purpose Orchestra includes service oriented patterns in its architecture. The basic principle of a service oriented architecture relies on the fact that all system are modeled as abstract services. Due to this abstraction, a loosely coupling between the systems is achieved. Du to this reduced coupling a higher flexibility is achieved whenever systems change or are replaced. Beside the idea of using abstract services, the idea of supporting publish/subscribe scenarios is useful.

Signals

Publish/subscribe is a common principle in informatics. Whenever a business event occurs, the event source can publish the signal to an underlying bus infrastructure. The bus infrastructure is responsible for sending the signal to all registered receivers. The sender doesn't know about the possible recipients. This leads also to a loosely coupling, whereby possible receivers can be added, removed changed without changing the sender. When a receiver is interested on a special signal, an subscription is created. Such a subscription can be defined as volatile or persistent. A volatile subscription receives only data when the receiver is active, otherwise the signals are discarded. When a persistent subscription is created, all events are stored and queued by the underlying service bus. When a receiver is active, the data is handed over to the recipients. If a recipient is inactive, data data is buffered until a delivery is possible.

Service Provider

A service provider is comparable to the implementation of a service. In case of Orchestra an implementation is done by mapping the service operations to technical elements of Orchestra like process models, mappings or channels. Furthermore, it is possible to specify different bindings for a service provider. A binding defines a kind of protocol that defines the way how a service can be accessed from external. Currently Orchestra supports the SOAP-Protocol and optimized protocol for invocation of internal Orchestra services.

Service Declarations

A service declaration is comparable to the client view of a service. Whenever Orchestra wants to invoke a service, a service declaration (proxy) is necessary that can be used to invoke the underlying service. The service declaration contains the supported operations, bindings and communication endpoints necessary for accessing a service implementation. Currently Orchestra supports the SOAP-Protocol and optimized protocol for invocation of internal Orchestra services.